Add support for inline assembly for the amdgpu backend (the
amdgcn-amd-amdhsa target).
Add register classes for `vgpr` (vector general purpose register) and
`sgpr` (scalar general purpose register).
The LLVM backend supports two more classes, `reg`, which is either VGPR
or SGPR, up to the compiler to decide. As instructions often rely on a
register being either a VGPR or SGPR for the assembly to be valid, reg
doesn’t seem that useful (I struggled to write correct tests for it), so
I didn’t end up adding it.
The fourth register class is AGPRs, which only exist on some hardware
versions (not the consumer ones) and they have restricted ways to write
and read from them, which makes it hard to write a Rust variable into
them. They could be used inside assembly blocks, but I didn’t add them
as Rust register class.

There is one change affecting general inline assembly code, that is
`InlineAsmReg::name()` now returns a `Cow` instead of a `&'static str`.
Because amdgpu has many registers, 256 VGPRs plus combinations of 2 or 4
VGPRs, and I didn’t want to list hundreds of static strings, the amdgpu
reg stores the register number(s) and a non-static String is generated
at runtime for the register name.

Use just two variants for SGPRs and VGPRs, each with an int for the
register size in bits.

Remove support for 64-bit vector types to make it simpler.

…group killing

The documentation for the `format_into` methods on unsigned integers
still said "in signed decimal format". Change them to say "unsigned".

…acrum

Include vendored sources in the rust-src component

In the future this can be used by build-std, but until then it is still useful for allowing rust-analyzer to work offline.

This increases the unpacked size by 24MB (from 116MB to 140MB) and the compressed size by only 2MB (from 18MB to 20MB)

Add inline asm support for amdgpu

Add support for inline assembly for the amdgpu backend (the amdgcn-amd-amdhsa target).
Add register classes for `vgpr` (vector general purpose register) and `sgpr` (scalar general purpose register).
The LLVM backend supports two more classes, `reg`, which is either VGPR or SGPR, up to the compiler to decide. As instructions often rely on a register being either a VGPR or SGPR for the assembly to be valid, reg doesn’t seem that useful (I struggled to write correct tests for it), so I didn’t end up adding it.
The fourth register class is AGPRs, which only exist on some hardware versions (not the consumer ones) and they have restricted ways to write and read from them, which makes it hard to write a Rust variable into them. They could be used inside assembly blocks, but I didn’t add them as Rust register class.

There is one change affecting general inline assembly code, that is `InlineAsmReg::name()` now returns a `Cow` instead of a `&'static str`. Because amdgpu has many registers, 256 VGPRs plus combinations of 2 or 4 VGPRs, and I didn’t want to list hundreds of static strings, the amdgpu reg stores the register number(s) and a non-static String is generated at runtime for the register name.

Tracking issue: rust-lang#135024

…JonathanBrouwer,mu001999

Support defaults for static EIIs

Tracking issue: rust-lang#125418

rust-lang#154193 added EII support for statics, but left default implementations for "a followup PR". This PR implements it.

Maybe I should remove `no-prefer-dynamic` if rust-lang#156577 is accepted.

…imonSapin

library: Fix std compilation for espidf target in unix::process

Fixes a regression on the riscv32imac-esp-espidf target caused by commit 7bf5fe7 (linked issue rust-lang#156537) . The unix_kill_process_group feature attempts to use libc::SIGKILL, which is not supported on the espidf target.

Discussed in `esp-idf-sys` issue: esp-rs/esp-idf-sys#419

…monSapin

Change division to multiplication in floating-point midpoint

Multiplication is faster than division on most (all?) platforms. While the optimizer will handle this, there is really no point in relying on that. Using multiplication directly will not have any drawbacks and are numerically identical (in this case since 1.0 / 2.0 == 0.5)

Consider the examples at https://godbolt.org/z/oMvb9vobG where it is clear that the non-optimized version uses division, while the optimized version uses multiplication.

…imonSapin

Fix typo in `format_into` docs: signed -> unsigned

The documentation for the `format_into` methods on unsigned integers
still said "in signed decimal format". Change them to say "unsigned".